Desallocation memory response time

SystemAdmin - Thu Mar 04 08:38:03 EST 2010
Yes, DOORS is a memory hog, especially all strings will be left in memory as there is no garbage collection. Buffers can be deleted from memory, but often the effect is not so large, as you have to handle the data as strings at some point.

What fo you mean by 100 Mo or 1 Go??

As for skip lists: if you insert string values into skip lists, the individual strings will be in memory even though you delete the skip list.

Do not know about timings for these operations, but generally, the more memory you consume, the slower everything works.

Attached is an old Telelogic technical tip paper on DXL memory consumption.

llandale - Thu Mar 04 14:05:22 EST 2010

An individual module isn't going cause serious degredation.

One problem we found is that residually opened modules stay open, such as when you follow a link or access dxlAttr or Layouts that do the same thing. I've got a small suite of 'close everything up' that when 'too many' modules are currently open, it closes all modules that were not open when the script began. I arbitrarily set 'too many' to 40.

Another is to be sure to open modules Invisibly; this is especially true if you have remote custom 'addins' defined. When visible, critical also is to bypass the default view and load the standard view. Routinely do this: Module mod = read(NameModFull, false, true).

String parsing is a hog. Avoid concatenation inside a loop. Look at this code. See the completely rediculous explosion in response when concatenating strings, between 10,000 loops and 12,000 loops; from a palty 2 seconds to almost 2 minutes. Whereas the Buffer solution has linear response.

/* Start Mem Use = 900mb
    Results:
NumLoops = 20,000
    109 mSecs, Wasted space =    108890
  xxxx far too long

NumLoops = 12,000
     78 mSecs, Wasted space =     60890
111,922 mSecs, Wasted space = 349215495

NumLoops = 10,000
     62 mSecs, Wasted space =     48890
  2,188 mSecs, Wasted space = 239429495

*/
pragma runLim, 0
int     i
int     NumLoops = 10000
int     Wasted = 0
string  Result = ""
string  Temp
Buffer  bufResult = create()
bool    DoBuff = confirm("Do buffer Test")
// int          TimeStart = intOf(today())
int     TimeStart = getTickCount_()
 
for (i=0; i<NumLoops; i++)
{  if (DoBuff)
   {  Temp = i ""
      bufResult += " "
      bufResult += i ""
      Wasted += length(Temp) +1
   }
   else
   {  Result = Result " " i ""
      Wasted += length(Result)
   }
}
print (getTickCount_() - TimeStart) " mSecs, Wasted space = " Wasted "\n"
 
delete(bufResult)

I'm suspecting that DOORS reserves a big string table space when it starts, and slows down drastically when that space is exhausted and more is requested, incrementally, from the OS.

• Louie

SystemAdmin - Mon Mar 12 20:40:31 EDT 2012
Louie: Are you able to share the technique you use to get a handle on what modules are currently open so that they can be closed to release memory?

Everybody: I'm running into an out of memory situation with a "for item in current Project do" loop that opens every module and loads every view. There are hundreds of modules and thousands of links to lots of other modules. Even though I close each module after I process it, after about 130 modules I hit the 2GB mark and DOORS dies. I suspect that other modules are being opened (and remain open) due to layout DXL in views and are not being closed. I have been careful to avoid strings and use buffers instead. Thoughts?

Thanks!
Bob3

SystemAdmin - Tue Mar 13 09:08:00 EDT 2012
for m in database do {
...
}
where:

m is a variable of type Module

Operation
Assigns the variable m to be each successive open module (for which the user has read access) in the database.
or
for m in project do {
...
}
where:

m is a variable of type Module
project is a variable of type Project

SystemAdmin - Tue Mar 13 13:30:14 EDT 2012
SeanF, thanks for your response.

My concern with this approach is that if there are a lot of modules, this loop could increase my script's runtime. You see, I am already interating through all the modules in the project. With this approach, I would be iterating through all the modules in the project (closing any that are open) as many times as there are modules in the project.

Is there a more nuanced way of only closing those modules that are open (visibly and invisibly), rather than iterating through all modules?

SystemAdmin - Mon Mar 12 20:40:31 EDT 2012
Louie: Are you able to share the technique you use to get a handle on what modules are currently open so that they can be closed to release memory?

Everybody: I'm running into an out of memory situation with a "for item in current Project do" loop that opens every module and loads every view. There are hundreds of modules and thousands of links to lots of other modules. Even though I close each module after I process it, after about 130 modules I hit the 2GB mark and DOORS dies. I suspect that other modules are being opened (and remain open) due to layout DXL in views and are not being closed. I have been careful to avoid strings and use buffers instead. Thoughts?

Thanks!
Bob3

SystemAdmin - Tue Mar 13 13:30:14 EDT 2012
SeanF, thanks for your response.

My concern with this approach is that if there are a lot of modules, this loop could increase my script's runtime. You see, I am already interating through all the modules in the project. With this approach, I would be iterating through all the modules in the project (closing any that are open) as many times as there are modules in the project.

Is there a more nuanced way of only closing those modules that are open (visibly and invisibly), rather than iterating through all modules?